It surprised me that this was just like that when the function was introduced - I thought the earlier return was likely to have been from a bug fix that was done later. That said, what are the consequences of fixing it? Does this ensureUriEncoded function work correctly? Did @thornjad have the early return for testing purposes and simply forgot to remove it, or did he know there was a problem with the implementation and put the early return here as a temporary measure?

Also, why was this implemented at all? The test uses encodeURI, a builtin that appears to have the same purpose. It looks like these do the same thing too:

> encodeURI('http://localhost:8080/file?\x0cfoo')
'http://localhost:8080/file?%0Cfoo'
> ensureUriEncoded('http://localhost:8080/file?\x0cfoo')
'http://localhost:8080/file?%0Cfoo'

I'm leaning toward using encodeURI wherever ensureUriEncoded is used, but I need some evidence of manual testing before I can merge this (unless I find time to do that myself).

Good point. With the early return text the function currently does nothing, since the second return is unreachable. Removing it simply restores the intended behavior of encoding characters matched by nonUrlSafeCharsRgx. I also tested the example above and it produces the same result as encodeURI